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Abstract 

This paper reports on our industry-academia project of using a 
functional language in business software production. The general 
motivation behind the project is our ultimate goal of adopting an 
ML-style higher-order typed functional language in a wide range 
of ordinary software development in industry. To probe the feasi- 
bility and identify various practical problems and needs, we have 
conducted a 15 month pilot project for developing an enterprise re- 
source planning (ERP) system in SML#. The project has success- 
fully completed as we have planned, demonstrating the feasibil- 
ity of SML#. In particular, seamless integration of SQL and direct 
C language interface are shown to be useful in reliable and effi- 
cient development of a data intensive business application. During 
the program development, we have found several useful functional 
programming patterns and a number of possible extensions of an 
ML-style language with records. This paper reports on the project 
details and the lessons learned from the project. 

Categories and Subject Descriptors D.3.2 [Language Classifica- 
tions]: Applicative (Functional) Programming 

Keywords Standard ML; Business Application; Database Pro- 
gramming; Record Polymorphism 

1. Introduction 

Advantages of ML-style polymorphic languages have been widely 
recognized in academia. Higher-order functions allow program- 
mers to write elaborate code in a concise and declarative manner. 
Polymorphic typing and a sophisticated module system enhance the 
reliability of the system through static type checking and data ab- 
straction. Despite these advantages, ML-style languages have not 
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yet been widely used in industry. Among major software compa- 
nies in Japan, for example, very little is known about ML and there 
is virtually no experience in using ML in software production. As a 
developer of an ML-style language SML# [13], we find this situa- 
tion unfortunate. As a software company, we also find an ML-style 
language as a significant potential in enhancing the productivity 
and reliability in our ordinary software production. Declarative pro- 
gramming, static type inference, signature checking, safe and scal- 
able module system should all have significant positive impact not 
only in symbolic computation such as theorem provers and com- 
pilers but also in ordinary software development such as inventory 
management, management accounting, and resource planning. 

Based on these general observations, NEC Solution Innovetors, 
Ltd. and Tohoku University have started joint research aiming at 
establishing a programming environment of SML# for general soft- 
ware development. SML# is a new ML-style language being devel- 
oped at Tohoku University [13]. In addition to its conformance with 
the Definition of Standard ML [8], it supports several practically 
useful features including: seamless integration SQL (the standard 
database query language), direct C language interface, concurrent 
GC and native multithreading support on multicore CPU. Among 
them, seamless SQL integration and direct C language interface 
should be particularly useful in data intensive business software 
development. 

As the first step in this endeavor, we have conducted a 15 month 
pilot project to develop an enterprise resource planning (ERP) sys- 
tem in SML#, which will be used in NEC Solution Innovetors, Ltd. 
to manage the company's projects and related resources. The goal 
of this project is to probe the feasibility of SML# and to identify 
various practical problems and needs in using SML# for ordinary 
software development in industry. As we shall explain in the next 
section, an ERP system is chosen by considering this goal. The sys- 
tem development has successfully completed, and the ERP system 
is currently under evaluation with the actual databases containing 
the company's project, personnel and accounting information. Al- 
though we do not have statistical measurement of the productivity 
of using SML# at this moment, the development has been com- 
pleted as we planned with the expected productivity. The SML# 
features of the seamless database integration and direct C library 
interface have indeed been shown to be useful. 

In addition to the completed ERP system, we have obtained 
project management skills in designing and developing business 
applications in ML. As a software development project using a new 
language in a company, we had to manage a number of problems in- 
cluding programming education, software quality control, and de- 
sign method. After sorting out these problems, the program devel- 
opment has been smoothly done with a satisfactory result. During 
the development, we have found several useful polymorphic pro- 
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gramming idioms that can serve as functional design patterns for 
data intensive business software development in ML. Another im- 
portant assets we have acquired through this project are the insights 
toward improving ML-style languages. Experience with database 
programming revealed the needs and interesting research issues 
concerning flexible manipulation of records in a polymorphic lan- 
guage. These lessons learned from our project should also be useful 
for anyone who plans to adopt an ML-style language in industry. 

The rest of the paper is organized as follows. Section 2 describes 
the overview of the system we have developed and miscellaneous 
problems we have tackled in carrying out the project. Section 3 de- 
scribes the system architecture and the details of the development. 
Section 4 discusses evaluation of the project management and new 
findings through the project. Section 5 discusses the lessons learned 
through the project and suggests future improvement of ML-style 
languages. Section 6 reports the current status and initial evaluation 
of the developed system. Section 7 concludes the paper with a brief 
description of our future plan. 

2. The Project Overview 

This section outlines the system we have developed, and discusses 
miscellaneous problems we have overcome out in carrying out the 
project. 

2.1 The target ERP system 

We have set our goal to develop an ERP system that has the 
following functionality. 

1. It reports the current status of each software project in the 
company based on the company database which are updated 
frequently. 

2. It simulates the future costs and expected profits of existing and 
planned projects under a given set of parameters on resources 
entered by the operator. 

There have been growing needs among managers and executives 
in the company for accurate estimate of each project status at any 
given time, which is not easily available in the currently used sys- 
tem. So an ERP system having these functionalities is itself a highly 
desired system in the company. In addition, this target system is 
appropriate for our purpose of probing the feasibility and identifies 
various practical problems in using SML#. Firstly, it represents a 
typical business application involving extensive database accesses, 
various business logic programming, and report generation. Sec- 
ondly, since we do not have much previous experience in develop- 
ing a similar system, the development must contain an entire soft- 
ware development process: requirement identification, system ar- 
chitecture selection, system design, program development, testing 
and evaluation. Finally, through the use of the developed system in 
NEC Solution Innovetors, Ltd., we can evaluate the system's main- 
tainability and extensibility as well as its performance and overall 
quality. 

2.2 Miscellaneous issues in carrying out the project 

To carry out the first software development project using ML in the 
company, we had to sort out a number of problems before starting 
the program development. We list some of them below. 

• Programming education. 

Since none of the software engineers in NEC Solution Innove- 
tors, Ltd. had previous experience in ML, we have set up an ed- 
ucation course on ML programming and the related techniques. 
We have designed and given a 6 day intensive course, covering 
ML programming basics, SML# features, system programming, 
and an example system development. 



• Acquiring domain knowledge. 

As stated earlier, we do not have much previous experience in 
an ERP system development. So we have studied the basics of 
management accounting, and have analyzed the company's ac- 
counting principles and resources. Sharing these domain knowl- 
edge has been crucial for our combined development team to 
understand, analyze and review the program code. 

• Software quality control. 

The software development must conforms to the ordinary qual- 
ity standard set by the company. This requires to make doc- 
uments for: requirement definition, primary design, functional 
design, program design, and test design. Since there is no stan- 
dard method available for ML, we had adopted the existing 
standards for most of the cases and have adjusted during the 
project . For example, we have adapted class diagram with ML- 
style signatures for program design. 

• Design method. 

We had to develop and share a design method for the system, 
i.e. how to analyze the problem and how to represent it as a 
programming system. For this purpose, again, we have found 
very little resources for ML-based system development. As a 
compromising starting point, we have adopted the model-view- 
controller approach [6], and have tried to refine their compo- 
nents for ML based system. One positive outcome of this effort 
is abstract model construction we shall present in Section 4.1. 

Once we had sorted out these problems, program development has 
been largely smooth. 

3. The ERP System 

This section describes the architecture design and the details of the 
system development. 

3.1 The system architecture 

To design the overall architecture of this system, we regard the 
ERP system as a web application and decompose the system into 
its major components by adopting the model- view-controller archi- 
tecture. We then design the system by elaborating each component. 
The following are the final structure of the system. 

• The Model. This part consists of SML# modules realizing 
the services the ERP system offers, including current status 
reporting and a several forms of simulations. The set of modules 
are organized into the following two layers. 

1. Persistent data (raw models). Most of the data are stored 
in a large relational database system serving through SQL 
Server. Figure 1 shows a simplified ER diagram of the 
database schema. In the actual database, table names and 
column names are represented in Japanese and they are di- 
rectly handled by SML# programs. It contains the current 
status of company's various resources, including projects, 
employees, contracts and orders and is updated frequently. 
This database is directly accessed through SML# SQL inte- 
gration [12]. In addition, the system reads data files in CVS 
and TVS formats, containing semi-stable data such as the 
current labor costs for each rank of employees, and the bud- 
gets of the current half year term. 

These data are represented as a set of ML modules and 
are regarded as raw models used by the abstract models 
described below. 

2. Abstract models. They are modules that realize the required 
services such as status reporting and several form of simu- 
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Figure 1. A Simplified ER Diagram of the Database 



lations. They are implemented by ML programs using raw 
models. 

This two-layered organization is our new design patterns that 
refines conventional MVC pattern, which we describe in details 
in Section 4.1, 

• The Controller. A set of functions that are called from the 
dispatcher function to perform appropriate action according to 
the user request. The dispatcher function is called from main 
function of the web application framework described below, 
and performs the following loop. 

■ get a user request, 

■ initialize the time, 

■ analyze the user request and call the corresponding con- 
troller function, 

■ generate a view and return a response to the user. 

• The View. This part consists of a set of ClearSilver template 
files for various report formats. These files are manipulated by 
the SML# ClearSilver binding described below. 

• Libraries 

■ Web Server Framework. A simple framework written in 
SML# that provides datatypes for requests, responses and 
forms, and the sever function 

main : (request -> response) -> unit 

■ Common Libraries including those for CVS and TVS file 
parsers, time and date format conversions. 



_require "basis. smi" 
_require "./form. smi" 
_require "./Log. smi" 
_require ". /Exception. smi" 
_r equire " . /Fcgi . smi " 
structure Server = 
struct 

datatype method = GET I POST 
type request = ... 
type response = ... 

val main : (request -> response) -> unit 
val uriOf : string list -> string 
end 



Figure 2. Interface File Example : Web Server Framework 



■ Global functions for system configuration and logging. 

■ External (third party) Libraries 

— FastCGI for web server framework. C API (FCGI_getchar 
etc) are directly imported through SML# C FFI. 

— JSON parser. We have used Standard ML of New Jer- 
sey's implementation. 

— ClearSilver HTML Template System. We write a simple 
C stub functions and import them through SML# C FFI. 

— JavaScript Libraries: Bootstrap, Prototype, jQuery, cc- 
chart. 

3.2 The development details 

The development has been done in two stages: the prototype devel- 
opment and the development of the system version 1 . About 30% 
of prototype codes are re-used, and the rest are re-written in the 
version 1 system. Most coding has been done by NEC Solution 
Innovetors, Ltd. Tohoku University has developed the web server 
framework and provided the necessary language extensions and 
supports. To achieve industry strength ML coding, we have held 
weekly meeting for code review and re-factoring. This has been 
quite effective in enhancing the quality of the system and boosting 
ML programming skills of the project members. 

ML components have been developed using the separate compi- 
lation feature of SML#. For each major module, we first decide the 
initial interface by writing an interface file of SML#. As an exam- 
ple, Figure 2 shows the interface file of the web server framework. 
Using these interface files, we have developed each component sep- 
arately. For each SML# source file, SML# separate compiler pro- 
duces an object file in the standard ELF format. SML# object files, 
C object files and libraries are then linked together by SML#, which 
is invoked through the Unix make system. This model works effec- 
tively among our team. 

The developed system consists of about 25 k lines of code 
excluding third-party libraries, among which 12 k lines are written 
in SML#. The code size details are given in the following table. 



type 


files 


total size (k lines) 


SML# interface file 


61 


2.1 


SML# source file 


61 


9.7 


ClearSilver template 


17 


3.5 


c source file 


1 


0.09 


html files 


10 


5.4 


ess files 


11 


1.2 


js files 


6 


2.4 



The following table shows the summary of the production costs. 
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Figure 3. Information Window of the System 



type 


activities 


man-hour 




education & analysis 


320 


prototype 


design 


320 




coding and test 


1120 




education & analysis 


640 


version 1 


design 


320 




coding and test 


1280 



A new member has joined at the start of version 1 system. The 
relatively high education cost is inevitable for this project that 
adopts a new language and new method. Considering this and the 
fact that we have developed an entirely new system from scratch 
with problem analysis and prototype developing, we regard the 
development of the project efficient, and the overall development 
quite satisfactory. 

As we shall report in Section 6, the developed system is cur- 
rently under evaluation. Overall, the system shows expected be- 
havior. Figures 3 shows a simulation window. 

4. Evaluation of the Project and New Findings 

As we shall discuss in detail in the next section, we have found sev- 
eral needs of improvements of an ML-style functional language, 
but the overall development has been quite satisfactory. We have 
confirmed that functional programming and SML# features have 
contributed to the productivity of the project, as we have expected. 
We have also found and developed some useful programming pat- 
terns for data intensive business applications. In this section, we 
discuss some of them below. 

4.1 Abstract model construction that refines MVC pattern 

We started the system design by adopting the popular MVC pat- 
tern, where the notion of models represent data with a set of pro- 
cedures. In a simple web application such as a system to display 
a picture associated to some key, a model naturally corresponds 
to persistent data stored in a database system. The required pro- 
cedures are retrieving, updating, and deleting the designated data 
element. In this simple situation, a database can be properly ab- 
stracted through object-relational mapping. However, in a typical 
business application such as the one we have developed, large and 
complex data are stored in a relational database as a highly nor- 
malized (in the sense of relational database theory [7]) set of flat 
relations. For example, the company database we had to deal with 
in this project (whose outline is shown in Figure 1) has 15 tables, 
each has 4 to 103 columns. The total number of columns is 395. 
To retrieve a data for each user request, we have to make compli- 
cated database joins among a subset of 15 tables, taking account 



fun f indEmployeeNameByCode employeeCode = 
let 

infix andAlso == 
val r = SQL . f etchOne 
(_sqleval 
(let 

open SQL 

in 

_sql db => 

select #e.NAME as employeeName 
from #db.M_PDBS as e 

where (#e.PCD == (toSQL employeeCode)) 

end) 

(DBConnector . conn ())) 

in 

#employeeName r 
end 



Figure 4. SQL integration used in abstract model construction 



of the database schema design, and to project the results on some 
particular columns. User responses are then computed from the re- 
trieved column values. We do not think that a database consisting 
of 15 tables with 395 columns is exceptionally large. For such a 
large relational database with highly normalized schema, it is very 
difficult to make an object relational mapping that can deal with 
various user requests. 

The seamless integration of SQL in an ML-style language 
achieved by SML# provides an ideal solution to this problem. In 
SML#, database queries (SQL commands) are polymorphically 
typed ordinary ML expressions denoting a list of records. It is then 
a routine matter to use higher-order functions and to construct a 
desired data structure on top of whatever complex record struc- 
tures returned by a query expression. We conceptually regard this 
layer of computation, abstract model construction, which refines 
the usual MVC pattern, i.e. the conventional model M in MVC 
pattern is refined to two layers of raw models of databases and ab- 
stract models constructed by higher-order functions on top of raw 
models. 

Figure 4 shows a fragment of a simple function that is used in 
abstract model construction, where we replace the actual Japanese 
column names with simple labels. We note that _sql db => 
select ... is an expression having a polymorphic type, and not 
an ad-hoc embedding. See [12] for the details. This property guar- 
antees complete static typechecking through MLs polymorphic 
type inference. This feature completely relieves problematic run- 
time query failure due to schema mismatch. Considering the size 
of databases and complexity of SQL queries used, this property 
should otherwise be difficult to obtain. Seamless SQL integration 
in SML# enables the programmer to develop required abstract mod- 
els through easy, declarative, and type safe programming. This is 
the most contributing factor in productivity of our development. 

4.2 Data intensive programming with record polymorphism 

Record polymorphism of SML# provides a powerful mechanism 
for modular programming in data intensive application develop- 
ment. As we mentioned, database query results contain labeled 
records with a large number of fields. For example, a frequently 
appearing typical type in our system contains 35 fields. Each mod- 
ule processes only some subset of the fields. To organize a system 
consisting of a number of such modules in a modular and type safe 
way, record polymorphism plays a central role. For example, a util- 
ity function that filters out low-ranked software projects has the 
following interface type 
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val excludeE : [ ' a#{rank : rank} . 'a list -> 'a list] 

which represents the precise polymorphism and type constraint this 
utility function has. 

In addition to writing various utility functions through record 
polymorphism, we have also found several functional design pat- 
terns that have general usefulness. Here we show a typical one be- 
low. In our system, we generate result HTML files through Clear- 
Silver templates. This is done by filling each hole in a template 
with specific values. In order to organize this process in a modular 
and type safe way, we find the following pattern using polymorphic 
record update, which we present below. This pattern has not yet 
fully exploited in the current system; we plan to re-factor the sys- 
tem with this pattern in near future. Suppose we have two attributes 
A and B and that they are independently computed by two func- 
tions f illA and f illB. This is a simplified model of decomposing 
the template filling task into a set of independent modules. In an 
actual situation, {A, B} becomes a set of sets of attributes. This 
situation is cleanly represented by the following design pattern. We 
represent each field of type r as r option, where NONE indicates 
a non-filled hole and SOME v indicates the hole filled with v. The 
function f illA is then implemented as a function of the form 

fun fillA (x as {A = NONE, ...» = 

let val v = computing a value to be filled in A 

in x # {A = v} 

end 

I fillA (x as {A = SOME _, . ..}) = 
raise AlreadyFilled 

where x # {A = v} is polymorphic record update operation 
which creates a new record from x by modifying the field A. This 
function has the following polymorphic type. 

fillA : ['a#{A: r option}, 'a -> 'a] 

This type precisely represents the fact that f illA operates only on 
field A and that it can compose with any function that operates on 
any other fields, f illB has a similar structure. A template package 
is defined as a module containing the following 

val init = {A=N0NE , B=N0NE} 

fun check (x as {A=S0ME _, B= SOME _}) = x 

I check _ = raise ThereAreMissingField 
fun fill F = check (F init) 

where init represents the empty template, and fill invokes hole 
filling function F and dynamically ensures that all the fields are 
filled through function check. The controller to dispatch f illA 
and f illB can then be implemented as 

fun dispatch AB () = fill (fillB o fillA) 

by composing f illA and f illB functions. 

This record pattern scales to set of subsets of fields and is 
generally helpful in compositional development of a component 
having multiple attributes/aspects. 

4.3 Development with best-of-breed components 

In a large system development in industry, selecting best-of-breed 
components from available choices is essential. The direct C in- 
terface of SML# has greatly contributed to this practice in the 
project. As we show in Section 3, we have used several external li- 
braries such as FastCGI and ClearSilver. Figure 5 shows a fragment 
of FastCGI module written and used in the project. In this code, 
FCGI_- • • is a C function provided by the FCGI package. With this 
feature, we can directly import a library package almost instantly as 
far as the package provides a C API. SML#'s separate compilation 
system links the referenced packages. Through this mechanism, the 



structure FCGI = 
struct 

exception 10 of string 

val accept = _import "FCGI_Accept" : () -> int 
val finish = .import "FCGI_Finish" : () -> () 
val setExitStatus = 

.import "FCGI_SetExitStatus" : int -> () 
val FCGI_getchar = 

.import "FCGI_getchar" : () -> int 
fun get char () = 

SOME (chr (FCGI_getchar ())) 
handle Chr => NONE 

end 



Figure 5. FCGI binding through SML# C FFI 



programmer can select best suited packages from a rich collection 
of library packages with C API. 

5. Insights Towards Better Record Programming 

Manipulation of record structures is one of the central aspects in our 
ERP system. This should be true for many data-intensive business 
applications. In textbook examples, records are rather small and are 
typically used as parameters to a function or a datatype constructor. 
In business applications using databases, however, we frequently 
deal with records with a large number of fields. Experience with 
record programming in our project have given us various invaluable 
insights towards extending and improving record programming 
primitives in SML# and ML-style functional languages. In this 
section, we discuss some important ones. 

5.1 Uniform operations on a set of fields. 

A record often contains a set of related fields such as labor cost 
fields of all the months. We have often encountered cases of writ- 
ing similar or same code for each such field. Such a program would 
become much more concise and maintainable if the language sup- 
ports uniform operations such as map and fold for a set of record 
fields. Using first-class polymorphic field selectors, this can already 
be achieved in SML# to some extent. For example, summing up a 
given list F of fields in a record X can be coded as follows. 

foldr (fn (f,S) =>(f X + S)) 0 F 

For example, in SML#, we can write the following function 

fn X => foldr (fn (f,S) =>(f X + S)) 0 [#jan, #feb] 
: ['a#{feb: int, jan: int}. 'a -> int] 

that adds up jan and f eb fields in a given record. This polymorphic 
idiom is itself useful for cases where fields are accumulated to a 
single value. However, we often encounter the cases where each 
field of one record is accumulated to the same or corresponding 
field in another record. To deal with this situation, it is desirable for 
the language to contain a mechanism to treat labels as first-class 
entities so that we can write, for example, the code of the form: 

fn (X,Y) => 

foldr (fn (L, Y) => Y # {L = #L X + #L Y}) 
Y [<jan>, <feb>] 

This pseudo code would increment each of j an and f eb fields in Y 
record with the corresponding field in X record. <jan> and <feb> 
are hypothetical "label literals" which are bound to L and used 
as a label. This mechanism would significantly improve database 
programming. At this moment, we do not know whether or not such 
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extension is possible. We regard this an interesting future work on 
ML-style languages with records. 

It has been suggested to us that "Fieldslib" of Camlp4 [14] 
provides first class labels through type-directed code generation us- 
ing the language module system. We note however that the func- 
tionality we want is the ability to abstract a polymorphic pattern 
that access multiple records and creates new records according to 
a given set of labels. In a language where record types must be 
declared and field access are monomorphic, even addressing the 
problem of flexible and modular manipulation of record structure is 
difficult. We also note that, as shown above, field access functions 
in SML# are already first-class polymorphic functions, on which 
we can map and fold. 

5.2 Type-safe dynamic views on records. 

Another insight we have gained through our database programming 
is the usefulness of customized "views" on a large flat record. In a 
relational database schema, each table contains a normalized flat 
record. For those relational schema, we often encountered cases 
where some fields are properties of an entity determined by a key 
stored in another field. In such case, we have to write codes that 
transform a flat record into a nested record. Although there is no 
difficulty, writing each such code is tedious and makes the entire 
program lengthy. Since the code is determined by the source record 
type and the target record type, language support to provide a view 
that automatically generates those code from types is highly desir- 
able. We believe that previous results on functional type isomor- 
phism [1,5] can be used to integrate such a mechanism in SML# 
and other ML-like languages with records. 

Another observation we have during database programming in 
this project is that such a view should also support uniform treat- 
ment of implicitly enforced non-null constraint. In a relational 
schema, each field can contain the so called "null value" (unless 
otherwise explicitly specified as non-null). In our SQL integration, 
a field with null value is represented as an option type. However, 
this modeling is over strict; in may cases non-null constraint is 
omitted and context information such as some value in some field 
determines that theses fields are restricted to be non-null values. In 
such case, a view mechanism that dynamically checks and converts 
t option to t would be quite useful. The programmer then in- 
vokes a view only once when he/she knows that some set of fields 
are non-null. This mechanism would free the programmer from te- 
dious burden of checking the case of NONE and writing error hand- 
ing code. Again we believe this mechanism can be incorporated 
based on existing research on type isomorphisms mentioned above. 

5.3 Natural join in a programming language 

The pattern for template filling we have shown in Section 4.2 works 
reasonably well but is not ideal. It uses NONE of an option type 
to represent non-filled hole. A better approach would be to join 
locally computed set of attributes together to obtain a complete 
set of attributes to be filled in a template. Let r to be the set of 
attributes required for a template. Since r usually consists of a 
large set of attribute fields, we would like to decompose it into 
a set {ti, . . . , r n }, each of which is independently computed. In 
relational databases, this problem corresponds to decomposing a 
large relation r into a set of relations {n, . . . ,T n }. The desired 
relation is obtained by joining the set of component relations. In 
the relational model, this natural join operation is restricted to 
flat relations, but can be generalized to a term algebra containing 
records and sets [2, 9]. Using the notions developed in those works, 
we can regard this decomposition as an equation 

Ti U ■ ■ ■ U t„ = r 



where A U B is the least upper bound of two structures A and B. 
In our setting, we can think of this as an operation that recursively 
joins nested records. For example. 

{id: int ,proj : {name : string}} 
U {id: int ,proj : {rank: int}} 
= {id: int, pro j : {name : string, rank: int}} 

Using this notion, the template filling example can be better repre- 
sented as follows. 

We independently write functions to compute partial values 

val filli : unit -> n 

val fill„ : unit -> t„ 

each of which generates a piece of information as a nested record 
Ti. The template module can be 

fun fill (F:t) = ... 

which simply takes all the necessary information and fills the tem- 
plate completely. Its type safety is straightforwardly specified by 
the type constraint of nested record type r. Dispatching the set 
f illi , . . . , f ill„ of hole filling methods can be done 

fill (Join (fillj (), fill n ())) 

where Join is a nested application of a polymorphic nested record 
joining function _ j oin having the constrained type of the form: 

_join : 'a * >b -> 'c where ' c = 'a U 'b 

This solution is much more robust and modular since the complete- 
ness and consistence of the information needed to fill all the tem- 
plate holes are represented and checked by the type system. 

Although the current SML# does not support this operation, the 
necessary type theoretical machinery has been well established in 
[3, 10] and a language having this operation has been proposed 
[11]. A preliminary extension to the SML# type system has been 
done. In the extension, the following code can be written 

val fn (x,y) => _join(x,y) ; 

: ['a#{} ; 'b#{} ; 'c#OCa, 'b) . 'a * 'b -> >c] 

where ' c#-Q ( ' a , ' b) represents the least upper bound constraint. 
Currently, this extension is only for typing natural join of SQL 
commands, and does not support runtime execution. We hope that 
with further development of the implementation method, we can 
support user-level natural joins on nested records. 

Another possible approach to this problem would be to provide 
those elaborate record operations through language independent 
query [4]. It remains to be investigated how language independent 
query can be uniformly integrated in a host language polymorphic 
type system. 

6. Initial Evaluation of the Developed System 

Our industry-academia project of developing the ERP system has 
been completed at the end of March 2014. The current status of the 
system and our plan of its deployment are the following. 

1. After the completion, the system has been put into a trial use 
in a department of NEC Solution Innovetors, Ltd., where the 
development team belongs. The department consists of about 
60 engineers. 

2. The trial use have continued in the department for a few months. 
During this period, we have improved and polished the system. 

3. After the improvement, the company plans to start using the 
system in the division consisting of 5 departments for thorough 



172 



evaluation of the system's functionality and usability. This eval- 
uation will be completed before September 2014. 

4. After September 2014, the company plans to deploy the system 
in the entire Tohoku branch of NEC Solution Innovetors, Ltd. 

This current plan is almost exact scenario we had drawn up at 
the start of the project in December 2013. At that time, the Tohoku 
branch of NEC Solution Innovetors, Ltd. was an independent com- 
pany located in Tohoku, called NEC Software Tohoku, Ltd., which 
was merged into NEC Solution Innovetors, Ltd. in April, 2014. 

The steps 1 and 2 of the above deployment process have pro- 
gressed as we expected, and we have a positive perspective of com- 
pleting the entire deployment process as planned. In particular, im- 
provement of the system has been smoothly done. We have so far 
found several problems and shortcomings of the system. Some ma- 
jor ones include the following. 

• Long system start-up time. The system start-up time was much 
longer than we expected. Our analysis showed that this delay 
was due to redundant database connection calls and redundant 
calls to a date computation function. 

• Insufficient treatment of incomplete database states. One main 
goal of the system is to obtain real-time status of each project. 
To achieve this, the system uses the data stored in the company 
database, which is continuously updated. It is then inevitable 
that some data such as workloads of some project is partially 
filled, with some missing values. Such incomplete database 
states showed anomalous results. 

• Insufficient problem analysis and design. At the time of design- 
ing the system, we analyzed the company's business model and 
constructed our internal data model by extending the existing 
one for real-time status reporting. During the evaluation, we 
found that certain financial data in the company are only mean- 
ing full at the end of each month, and due to this, the system 
behaved anomalously in its few functions. 

We have successfully improved all the problems so far found. All 
the improvements have been done mostly by the company team. 
For long initialization time, we have reused an established database 
connection and have factored out date computation, resulting in sig- 
nificant reduction of the start-up time. For the incomplete database 
states, we have added codes to check the anomalous value, to warn 
the operator and to solicit the operator for missing values. We have 
also improved our internal model so that the system estimates those 
values that are only available at the end of each month. These im- 
provements have been done quite smoothly and efficiently with- 
out much help of the academic team. This experience confirms our 
confidence in maintaining and extending functional codes written 
in SML#. 

7. Conclusions and Future Plan 

We have reported on our project of developing an enterprise re- 
source planning (ERP) System using a functional programming 
language SML#. This project is our initial attempt to establish 
a programming environment for an ML-style higher-order typed 
functional language in wide range of ordinary software develop- 
ment in industry. The development project has successfully com- 
pleted as we have planned, demonstrating the feasibility of SML# 
in software production in industry. Evaluation of the project has 
confirmed the usefulness of the seamless SQL integration and di- 
rect C interface of SML#. By defining an abstract model layers 
on top of database access through higher-order functions, the ERP 
system has been easily structured in a natural and type-safe man- 
ner. The project has also given invaluable insights on possible fu- 
ture extensions to an ML-style language for data intensive business 



application developments, including uniform operations on record 
fields, type-safe dynamic views on records, and introduction of nat- 
ural join on nested records. 

This is our initial attempt toward establishing a functional pro- 
gramming environment for our general software development in 
industry, and a number of challenging issues remain to be inves- 
tigated before a functional language such as SML# can become 
a mainstream production language. Here we only mention one of 
them which is, we believe, the most important one. Throughout 
the project, which has been mainly carried out in NEC Solution 
Innovetors, Ltd., a major software company in Japan, we have fre- 
quently encountered a difficulty of analyzing a problem and making 
a basic program design for each programming task. This has been 
mainly due to the lack of common abstraction concepts in break- 
ing down a problem into programming component in a functional 
language. To improve this situation, we have identified and shared 
several patterns during the project both in coerce and fine grain. 
The notion of abstract model construction on database access we 
reported in Section 4. 1 and the polymorphic record update pattern 
in Section 4.2 are typical examples. Collecting such useful func- 
tional programming patterns and sharing them with industry will 
be of great help in disseminating functional languages in industry. 
As one of important future work of our academia-industry collab- 
oration, we would like to collect such patterns, and ultimately to 
establish functional programming methodology that is readily us- 
able in industry. 
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